Don't bother sorting build scripts

Turns out the tests don't actually need this "more deterministic" output and it
was also showing up relatively high in profiles (e.g. ~15% of a noop runtime) so
if this is necessary let's find a better way!

Add better diagnostics for rebuilding

This commit overhauls how a `Fingerprint` is stored on the filesystem and
in-memory to help provide much better diagnostics as to why crates are being
rebuilt. This involves storing more structured data on the filesystem in order
to have a finer-grained comparison with the previous state. This is not
currently surfaced in the output of cargo and still requires
`RUST_LOG=cargo::ops::cargo_rustc::fingerprint=info` but if it turns out to be
useful we can perhaps surface the output.

There are performance considerations here to ensure that a noop build is still
quite speedy for a few reasons:

1. JSON decoding is slow (these are just big structures to decode)
2. Each fingerprint stores all recursive fingerprints, so we can't just "vanilla
   decode" as it would decode O(n^2) items
3. Hashing is actually somewhat nontrivial for this many items here and there,
   so we still need as much memoization as possible.

To ensure that builds are just as speedy tomorrow as they are today, a few
strategies are taken:

* The same fingerprint strategy is used today as a "first line of defense" where
  a small text file with a string contains the "total fingerprint" hash. A
  separately stored file then contains the more detailed JSON structure of the
  old fingerprint, and that's only decoded if there's a mismatch of the short
  hashes. The rationale here is that most crates don't need to be rebuilt so we
  shouldn't decode JSON, but if it does need to be rebuilt then the work of
  compiling far dwarfs the work of decoding the JSON.
* When encoding a full fingerprint as JSON we don't actually include any
  dependencies, just the resolved u64 of them. This helps the O(n^2) problem in
  terms of decoding time and storage space on the filesystem.
* Short hashes continue to be memoized to ensure we don't recompute a hash if
  we've already done so (e.g. shared dependencies).

Overall, when profiling with Servo, this commit does not regress noop build
times, but should help diagnose why crates are being rebuilt hopefully!

Closes #2011

Add helper functions for reading/writing whole files

Adds some helpful error text if an error happens as well

Refactor Cargo's backend, again!

This commit started out identifying a relatively simple bug in Cargo. A recent
change made it such that the resolution graph included all target-specific
dependencies, relying on the structure of the backend to filter out those which
don't need to get built. This was unfortunately not accounted for in the portion
of the backend that schedules work, mistakenly causing spurious rebuilds if
different runs of the graph pulled in new crates. For example if `cargo build`
didn't build any target-specific dependencies but then later `cargo test` did
(e.g. a dev-dep pulled in a target-specific dep unconditionally) then it would
cause a rebuild of the entire graph.

This class of bug is certainly not the first in a long and storied history of
the backend having multiple points where dependencies are calculated and those
often don't quite agree with one another. The purpose of this rewrite is
twofold:

1. The `Stage` enum in the backend for scheduling work and ensuring that maximum
   parallelism is achieved is removed entirely. There is already a function on
   `Context` which expresses the dependency between targets (`dep_targets`)
   which takes a much finer grain of dependencies into account as well as
   already having all the logic for what-depends-on-what. This duplication has
   caused numerous problems in the past, an unifying these two will truly grant
   maximum parallelism while ensuring that everyone agrees on what their
   dependencies are.

2. A large number of locations in the backend have grown to take a (Package,
   Target, Profile, Kind) tuple, or some subset of this tuple. In general this
   represents a "unit of work" and is much easier to pass around as one
   variable, so a `Unit` was introduced which references all of these variables.
   Almost the entire backend was altered to take a `Unit` instead of these
   variables specifically, typically providing all of the contextual information
   necessary for an operation.

A crucial part of this change is the inclusion of `Kind` in a `Unit` to ensure
that everyone *also* agrees on what architecture they're compiling everything
for. There have been many bugs in the past where one part of the backend
determined that a package was built for one architecture and then another part
thought it was built for another. With the inclusion of `Kind` in dependency
management this is handled in a much cleaner fashion as it's only calculated in
one location.

Some other miscellaneous changes made were:

* The `Platform` enumeration has finally been removed. This has been entirely
  subsumed by `Kind`.
* The hokey logic for "build this crate once" even though it may be depended on
  by both the host/target kinds has been removed. This is now handled in a much
  nicer fashion where if there's no target then Kind::Target is just never used,
  and multiple requests for a package are just naturally deduplicated.
* There's no longer any need to build up the "requirements" for a package in
  terms of what platforms it's compiled for, this now just naturally falls out
  of the dependency graph.
* If a build script is overridden then its entire tree of dependencies are not
  compiled, not just the build script itself.
* The `threadpool` dependency has been replaced with one on `crossbeam`. The
  method of calculating dependencies has quite a few non-static lifetimes and
  the scoped threads of `crossbeam` are now used instead of a thread pool.
* Once any thread fails to execute a command work is no longer scheduled unlike
  before where some extra pending work may continue to start.
* Many functions used early on, such as `compile` and `build_map` have been
  massively simplified by farming out dependency management to
  `Context::dep_targets`.
* There is now a new profile to represent running a build script. This is used
  to inject dependencies as well as represent that a library depends on running
  a build script, not just building it.

This change has currently been tested against cross-compiling Servo to Android
and passes the test suite (which has quite a few corner cases for build scripts
and such), so I'm pretty confident that this refactoring won't have at least too
many regressions!

Touch up docs and use inline table syntax

This performs a pass over the docs, touching up sections in a few places and
also moving everything to using inline table syntax by default (the favorted way
to add a dependency)

Fix tests on nightly

Some output of failing tests have been tweaked, so update the associated tests.

Auto merge of #1828 - fhahn:multiple-package-parameters, r=alexcrichton

This PR for #1528 is still pretty rough (and so far only added multiple package support for tests), but I wanted to make sure the overall approach is fine.

I have made some progress and cargo is now able to compile and execute tests for multiple packages.

In order to execute the doc tests for multiple packages as well, I added `to_doc_test` to `Compilation` (used [here](https://github.com/fhahn/cargo/commit/8b8df3e8d5abfa638852f55730d2f3cb4eec66bc#diff-417e085367d0ce027505dfaa26a089d3R33)). Previously it only executed the doc tests for `Compilation.package`. Another option would be to change `Compilation.package` to be a `Vec<Package>`, because in order to execute the tests of multiple packages, multiple packages are compiled as "top level package". But this would require a changes at a couple of other places.

Use std::env::EXE_SUFFIX in new tests

Add support for multiple -p options to `cargo update`

closes #1528

Add support for multiple -p options to `cargo clean`

Use docopt's new syntax for repeatable options

Add support for multiple -p options to `cargo {bench, build, doc}`

Add a test for wildcard constraint warnings

Add a warning when packaging crates with wildcard dependencies

Auto merge of #2005 - sfackler:wildcard-warnings, r=alexcrichton

r? @alexcrichton

Any ideas on how to make a reliable test for this? Making a test with multiple dependencies on stuff off of crates.io seems to make output pretty nondeterministic wrt download and compilation ordering.

Add a test for wildcard constraint warnings

Auto merge of #2006 - alexcrichton:no-dylibs, r=brson

Currently it's not possible to inform Cargo about target-specific crate types,
so generating a hard error whenever a dylib is seen for a target that can't
produce dylibs is a little heavy. This commit disables management of the output
dylib (which won't actually exists) and relies on the compiler to print a
warning in the case of a dylib output on a non-dylib target.

Don't fail if dylib outputs aren't supported

Currently it's not possible to inform Cargo about target-specific crate types,
so generating a hard error whenever a dylib is seen for a target that can't
produce dylibs is a little heavy. This commit disables management of the output
dylib (which won't actually exists) and relies on the compiler to print a
warning in the case of a dylib output on a non-dylib target.

Add a warning when packaging crates with wildcard dependencies

Auto merge of #2003 - cesarb:issue-587, r=alexcrichton

Based on rust's mk/reconfig.mk

Fixes #587 and #1993

Regenerate Makefile if Makefile.in or configure change

Based on rust's mk/reconfig.mk

Fixes #587 and #1993

Auto merge of #1996 - aturon:cargo-features, r=alexcrichton

When I was looking for this in the docs, it was a bit confusingly buried.

r? @alexcrichton

Document use of features for `cfg` more prominently

Auto merge of #1994 - carols10cents:rust-updates, r=alexcrichton

I noticed the tests on my PR were failing and for once it wasn't because I messed up expectations involving path separators on windows!!!

They were failing because [nightly rust now has error code E0463](https://github.com/rust-lang/rust/commit/7358a5e8ea7c2ab0aaa76b503ef68161e44681a0) for "can't find crate" and the cargo tests weren't allowing for that. Just threw some `[..]`s in there so they should pass on all the rusts-- lmk if you'd like to have a comment that mentions the code could be added in there when rust 1.5 is released.

Speaking of rust trains, I also took this opportunity to change all the `connect`s to `join`s and remove the `allow(deprecated)`s since 1.3 was released! :sparkler:

Auto merge of #1991 - carols10cents:pipelinify, r=alexcrichton

Hi! This is an attempt to start refactoring some of the internals to be more like a pipeline, and eventually enable the kind of functionality I tried to add in #1968 without having to add as much duplication. Turns out there's a fair bit of duplication in the code today, I think this helps address it!

I may have totally gone against some abstractions... namely I made a way to create `Package`s from a `manifest_path` and a `config`, without needing a `Source`. I think it cleans up the code quite a bit, and I think makes things a bit more pipeliney in that the `Source` isn't updated until we really need it to be (as opposed to having to use `preload` to avoid updating it again). But I'm open to the possibility that I'm moving things around to where no one who knows the code well will be able to find them ;)

This *should* be a Real Refactor in the sense that these changes don't change behavior-- except in one test case, where the same error happens as did before, but it's going through a `chain_error` now so has a slightly different message.

Add a try! that I forgot

If at first you don't succeed to call try!, try try! again ;)

Keep the error message that starts with a lowercase letter

Test on Travis with Rust 1.1.0 and 1.2.0

Update tests to be tolerant of new error code [E0463]

Added in
https://github.com/rust-lang/rust/commit/7358a5e8ea7c2ab0aaa76b503ef68161e44681a0

Auto merge of #1995 - alexcrichton:less-recursion, r=alexcrichton

A few final nits and such taken care of, attempting to land now!

Touch up some style and comments in resolution

Avoid a to_vec in the resolver

Don't use an 8MB stack any more

Now that the resolver isn't recursive this shouldn't be necessary

Merge branch 'non-recursive-activate' of https://github.com/jyasskin/cargo

Auto merge of #1992 - carols10cents:cleanup, r=alexcrichton

Hiii! These are just a few small cleanup things that I took care of while working on #1991, but these should all be less controversial than that one is :)

Fixing typos and grammar in comments

Remove unnecessary PathSource update in cargo test

I don't think updating the source here is hurting anything, per se, it's
just unnecessary since ops::compile makes a PathSource and then calls
root_package, which will call update if it needs to.

Move test to a more appropriate location

This test isn't testing generate-lockfile at all-- it's generating a
lockfile with `\r\n` in it in the test itself and then testing that
building will succeed even if there are `\r\n`s in the lockfile.

Given that generate-lockfile could change and have no effect on this
test, I think this fits in better with the other `cargo build` tests.

Remove unneeded commented-out code

Extract a function for getting resolved packages from a registry

This code was happening in both cargo fetch and cargo compile and had a
slightly different error message in each ;)

Remove registry preload and avoid updating sources prematurely instead

So registry preloading was added[1] to avoid updating the root path
multiple times unnecessarily, since that's an expensive operation. But
with Package::from_path, we can get the root package just from a
manifest and a config without having to update the whole path source.

So now we don't have to remember to preload the registry if we've
already updated a source and want to use the registry later. Instead, we
just avoid loading the source initially and let the registry do it when
it needs to -- which is now in resolve_with_previous.

This does cause one tested error message to happen slightly later than
it used to, but it still happens.

[1] - ef8c651af

Remove dependency on Source if we only want a Package

As alluded to in the previous commit, we don't actually need a Source at
all in order to be able to get a Package given a manifest and a config.

Extract contructor for Package where only root_package is needed

There are many places where both source and its root_package() are used,
but in these places, the only reason the source is created is to get to
the root_package.

This just extracts the source creation into a Package constructor for
now, but I think this can be made to not use source at all.

Update source when getting its root_package

This way, callers who want source.root_package() don't have to remember
to call source.update() before that. Since source.update() is a noop if
the source has already been updated, there's not a reason I could see to
raise an error instead of just calling it.

The one remaining place that calls source.root_package() that is still
calling source.update() immediately before is in bin/read_manifest,
where the errors from update() are mapped to CliErrors.

Make Dependency cheap to copy by having it store a refcounted inner object.

Auto merge of #1988 - alexcrichton:bump, r=brson

I'll tag 0.5.0 with the previous commit after this is merged.

Bump to 0.6.0

Auto merge of #1986 - mneumann:dragonfly-snapshot, r=alexcrichton

http://www.ntecs.de/downloads/rust/cargo-nightly-x86_64-unknown-dragonfly.tar.gz

This is the 0.5 version of cargo as it's much harder to build an old snapshot.

Add snapshot for DragonFly

http://www.ntecs.de/downloads/rust/cargo-nightly-x86_64-unknown-dragonfly.tar.gz

This is the 0.5 version of cargo as it's much harder to build an old snapshot.

Auto merge of #1949 - nicokoch:fix-1904, r=alexcrichton

This flag can be used to force cargo to run all tests, even if previous
tests failed. See #1904

Various small changes to cargo_test and friends.

- Reworked CargoTestError to contain Vec<ProcessError>
- Remove #[allow(trivial_casts)]
- Coding style fixes

Restructure cargo_test code and introduce CargoTestError

Auto merge of #1981 - alexcrichton:git-stamp-if-dead, r=brson

We already take this strategy for extracting tarballs from crates.io for
example, so this just applies the same strategy to checkouts of git repos.

Closes #1979

Use a stamp file to protect against corrupt checkouts

We already take this strategy for extracting tarballs from crates.io for
example, so this just applies the same strategy to checkouts of git repos.

Closes #1979

Fix another round of comments.

Auto merge of #1975 - alexcrichton:dont-capture-rustdoc, r=brson

We already started doing this for the compiler awhile back, so this just brings
rustdoc up to the same parity

Auto merge of #1972 - alexcrichton:update-curl, r=brson

Includes a fix for #1937 to not panic on downloading crates on newer OSX
versions.

Closes #1937

Don't capture rustdoc output for transitive deps

We already started doing this for the compiler awhile back, so this just brings
rustdoc up to the same parity

Auto merge of #1974 - alexcrichton:dont-document-build, r=brson

They're not actually relevant to the documentation, so omit them.

Don't document build dependencies

They're not actually relevant to the documentation, so omit them.

Auto merge of #1973 - alexcrichton:cargo-doc-release, r=brson

While this may not necessarily make sense all the time, this enables Cargo to
not rebuild anything if a `cargo build --release` was previously executed.

Add --release flag to `cargo doc`

While this may not necessarily make sense all the time, this enables Cargo to
not rebuild anything if a `cargo build --release` was previously executed.

Auto merge of #1969 - carols10cents:really-use-git, r=alexcrichton

Fixes #1210. If either `--vcs git` or `--vcs hg` is specified, assume
that means the user really wants the new project to use that VCS, even
if the project's location would be beneath an existing repository.

This was surprisingly easy! And would make me so happy-- my home dir is a git repo :)

Update curl bindings

Includes a fix for #1937 to not panic on downloading crates on newer OSX
versions.

Closes #1937

If --vcs flag specified, use vcs even if under an existing repo

Fixes #1210. If either `--vcs git` or `--vcs hg` is specified, assume
that means the user really wants the new project to use that VCS, even
if the project's location would be beneath an existing repository.

Round 2 of review:

* Converted pre-existing trace!s back from debug!
* Computed `cur` from the top-most frame instead of storing it.
* Wrapped to 80 columns.
* Removed prev_active and all_candidates from `BacktrackStack`
* Removed unnecessary type annotations.
* Called activation_error() only when starting to backtrack, since it bailed
  early when passed an error anyway.

Auto merge of #1966 - alexcrichton:fix-doc-again, r=huonw

It's possible to have multiple dependencies of the same name for a project if a
dependency shows up multiple times as a target-specific dependency. This means
that we can't just find the first one with the relevant name and assume it's the
right one, we instead need to check all of them.

Fix documenting target-specific dependencies for real

It's possible to have multiple dependencies of the same name for a project if a
dependency shows up multiple times as a target-specific dependency. This means
that we can't just find the first one with the relevant name and assume it's the
right one, we instead need to check all of them.

Auto merge of #1961 - alexcrichton:fix-doc-target-specific, r=huonw

The recent change in #1939 ended up accidentally pulling in irrelevant
platform-specific dependencies into a normal `cargo doc`, causing those builds
to fail. This change tweaks the logic for calculating documentation dependencies
to account for filtering based on the relevant platform.

Auto merge of #1964 - steveklabnik:doc_fix, r=alexcrichton

This has changed, apparently.

Fix syntax in build-script

This has changed, apparently.

Auto merge of #1963 - Frederick888:master, r=alexcrichton

The most common case is that if `cargo` is not installed to  `/usr` but somewhere else such as `/usr/local` (is this the default install prefix? don't remember...), user will see `cargo: command not found` after `sudo su` executed.

P.S. sorry for previous wrong PR... there was a redundant commit.

avoid warning when cargo not found

Auto merge of #1959 - lucab:lucab/skip-dotdir, r=alexcrichton

Cargo recursively looks for TOML manifest into child directories,
sometimes getting into unrelated files when exploring hidden
directories (eg. quilt .pc).

This commit lets cargo skip dot directories, to partially avoid
the issues described in #1423.

Signed-off-by: Luca Bruno <lucab@debian.org>

Only document platform-relevant dependencies

The recent change in #1939 ended up accidentally pulling in irrelevant
platform-specific dependencies into a normal `cargo doc`, causing those builds
to fail. This change tweaks the logic for calculating documentation dependencies
to account for filtering based on the relevant platform.

path: do not recurse into hidden/dot directories

Cargo recursively looks for TOML manifest into child directories,
sometimes getting into unrelated files when exploring hidden
directories (eg. quilt .pc).

This commit lets cargo skip dot directories, to partially avoid
the issues described in #1423.

Signed-off-by: Luca Bruno <lucab@debian.org>

Reset `parent`, `cur`, and `dep` when backtracking.

Fix @alexcrichton's comments.

Merge past #1939.

Auto merge of #1960 - alexcrichton:build-static, r=huonw

There's no real reason to eagerly link build scripts dynamically as they're not
going to benefit that much from dynamic linking. Most of the time they only have
one dynamic dependency, libstd, and most other Rust programs don't link it
dynamically so there's not really many space savings either.

Don't link build scripts dynamically

There's no real reason to eagerly link build scripts dynamically as they're not
going to benefit that much from dynamic linking. Most of the time they only have
one dynamic dependency, libstd, and most other Rust programs don't link it
dynamically so there's not really many space savings either.

Auto merge of #1939 - impl:resolve-deps-with-host-triple, r=alexcrichton

This fixes a specific issue with platform-specific dependencies of build dependencies when cross-compiling. The gist of the problem is that when dependencies are initially resolved, only the target platform is considered, which can cause the later analysis of the graph by the custom build process to miss dependencies.

I fixed the issue by including both target and host platforms in the dependency resolution process. I'm brand new to the Rust ecosystem and language, so I'm not sure if this is the right route architecturally, or if my code is even remotely acceptable. Any feedback would be greatly appreciated!

I've also included a test case to demonstrate the problem; it fails against the current master.

Thanks!

Auto merge of #1955 - carols10cents:even-more-manifest-path-consistency, r=alexcrichton

Hiii :) This builds on #1953, so if yinz like this better, I'll close that one.

This PR makes all commands that take `--manifest-path` (except locate-project, see below) behave in a consistent way with regards to invalid paths, and hopefully gives better error messages.

This DOES break some instances where commands were "working", ie, completing their command successfully, with some path that they decided was right, not necessarily exactly the path that was passed in though. I'm not sure how this impacts whatever backwards compatibility guarantees cargo has. Given that those cases weren't using a valid path to an existing Cargo.toml, hopefully no one is relying on that behavior?

So locate-project... I'm not sure what to do about that one, exactly... If we define `--manifest-path` as a path to a Cargo.toml, then uhhhh we've located the project, it's right where you told us it is ;) So I think we should change it to be `--search-path` or similar? I'm too sleepy to take care of that tonight, so I just left it out of the manifest path tests.

Use find_root_manifest_for_cwd for now-duped code in verify-project

Give better error messages for invalid manifest-paths

Inspired by https://github.com/rust-lang/cargo/pull/1182.
Fixes #1158, #1772, #1773.

Add tests for different kinds of invalid manifest paths

Make verify-project able to verify the current working dir project

All other commands use the Cargo.toml in the current directory if
--manifest-path is not specified; this makes verify-project consistent.

Add tests for different arguments given to verify-project

Right now, only passing --manifest-path a path to a Cargo.toml file
works, but I think not specifying a path and verifying the current
working directory, if it has a Cargo.toml, should work as well for
consistency with all the other commands that optionally take
--manifest-path.

Make read-manifest accept consistent manifest-path arguments

And also preserve the existing behavior of accepting an absolute path to
a directory containing a Cargo.toml for backwards compatibility.

Add tests for different arguments given to read-manifest

Right now, only passing --manifest-path an absolute path to the
parent directory of a Cargo.toml file works, but I think the other
tests should work as well for consistency with other commands that
optionally take --manifest-path.

Fix platform-specific dependency resolution for custom builds.

This change resolves dependencies against all possible platforms.
Activation of dependencies for a given target in the context of one
or more platforms is now wholly handled by cargo_rustc.

Make ::can_panic() return true on x86_64-pc-windows-msvc

Use internal error instead of ProcessError when multiple tests fail

Auto merge of #1943 - mseri:patch-1, r=alexcrichton

It maybe a tacky way, but I think that changing `util::without_prefix` is a bad approach. Maybe modify `process.build_command` could be another possible approach.

It could be worth to take more time to be sure to find the root of the problem. I am quite new to rust, if anybody can point out the right way of dealing with it, I will be happy to submit a new PR.

Fix for test on windows

Added test for issue #1942

Auto merge of #1931 - thirtythreeforty:printinfo, r=alexcrichton

Compare #1621.  Like that pull request, this one solves #984.

I have rewritten most of @pyfisch's logic to account for @alexcrichton's comments.  Specifically, this code will correctly handle adding/removing multiple versions of one package, as well as several packages with different sources, but the same name.

The output looks like this:

```
[georgev@desertvoice cargo]$ cargo update
    Updating registry `https://github.com/rust-lang/crates.io-index`
    Updating libc v0.1.8 -> v0.1.10
    Updating memchr v0.1.3 -> v0.1.5
    Updating num v0.1.26 -> v0.1.27
    Updating rand v0.3.9 -> v0.3.10
    Updating rustc-serialize v0.3.15 -> v0.3.16
```

Comments welcome.

r? @alexcrichton

Improved fix for the issue #1942

Print information about updated packages on cargo update

Closes #984.

Reformat lines with more than 100 characters